Business Analyst Community & Resources | Modern Analyst

3 Tips for Obtaining Requirements Sign-off

Stephanie Famuyide — Fri, 28 Feb 2014 18:28:00 GMT

Sign-offs are a sign that stakeholders agree with and approve the requirements that have been elicited and documented. There are multiple reasons why BAs seek stakeholder sign-offs and in some cases, it is not always clear whom it benefits.

While some methodologies like Agile do not involve a formal sign-off, requirements sign-off does add value. Here are 3 quick tips to help you get the sign-off you need:

1. Ensure that stakeholders understand the Requirements Specification Document (RSD)

Though you might be lucky enough to get a stakeholder to sign off on the RSD without understanding its contents (some people do sign documents without reading them), the ethical thing to do is seek their understanding and cooperation before asking them to sign. This approach is more likely to have a lasting positive effect on the project.

Analysts should avoid insisting on getting sign-off from stakeholders on RSDs that the stakeholders have not read, or have read but do not understand. They should instead, seek to get their understanding and commitment.

Key Takeaway: If you are planning to get a sign-off on your RSD, make sure stakeholders understand its contents. Discuss the contents of the document, take down their concerns, answer their questions, seek their opinions and let them feel involved. This is the ethical thing to do and it would help to build trust between you and your stakeholders. Lastly, you will get a “knowing” sign-off and not one that is given in ignorance or under duress.

2. Avoid spending an excessive amount of time getting the RSD signed off.

One disadvantage of sign-offs is that they take time. Most times, Analysts have to invest valuable company time in explaining the RSD to stakeholders, after all, they should understand the contents before signing off on it. This can introduce significant delays to the project, especially when stakeholders are difficult to locate or are in a different geographical location. How does the analyst justify placing lesser priority on other business analysis tasks to chase stakeholders' approval of requirements (signatures)?

Obtaining a sign-off becomes even more challenging in situations where stakeholders have not requested for the change. How does a stakeholder sign off on a requirement that did not come from him or her? The fact that a stakeholder has been designated as “process owner” does not signify that he or she is ready for the change.

Change projects may become necessary due to technical reasons, regulations or requests from other departments. Unless the benefits are obvious or the implications of signing off on requirements are mild to non-existent, don't expect stakeholders to give you an easy time.

Key Takeaway: Get all the relevant stakeholders involved as soon as you start the project. The more involved they are from the beginning, the more cooperative they will be when it's time for sign-off. Sign-off is also easier to obtain when requirements have been developed and documented in a collaborative fashion (using wikis, for example). In addition, requirements review sessions can be held to get the RSD signed off on time.

3. Avoid idle time while awaiting sign-off

In some organizations, developers do not write a line of code until requirements have been signed off. A delayed sign-off process can create idle time for developers (and analysts) who have been hired to complete the job. In some cases, developers would have already started the work before the requirements are signed off. This can be risky, however. Cancelled projects are only one consequence, though one can argue that the fact that the RSD has been signed off does not mean that the project cannot be cancelled.

Key Takeaway: Communicate constantly with stakeholders to ease the sign-off process. Where sign-off is not forthcoming, it's important to start asking yourself how important the project is to the stakeholders. Escalating to a higher authority may encourage the desired behaviour.

When sign-offs are sought without political undertones but with the right intentions, there are certainly benefits to be had. The sign-off process should be approached as an opportunity for discovery, which allows stakeholders to ask questions and get clarification on their areas of concern. A huge benefit to obtaining sign-off on requirements is that it is an indication that stakeholders are aware of, and are committed to seeing the solution live and in action.

Stephanie Famuyide, CBAP is a Business Analyst Practitioner, Blogger and a Lover of Life. Visit her Blog, Business Analyst Learnings for templates, practical tips and timely articles on business analysis.

A Call to Every BA: 8 Mistakes to Avoid in Writing Requirements Specification Documents

Stephanie Famuyide — Thu, 04 Apr 2013 06:53:00 GMT

According to the Strategies for Project Recovery report by PM solutions, based on 163 respondents, $74m invested in projects annually are at risk of failure. The report identified one of the top 5 causes of project failures as unclear, non-prioritized, contradictory, ambiguous and imprecise requirements.

Information like this is quite disconcerting, considering the fact that it is the responsibility of business analysts to elicit, manage and communicate requirements. As a first step to rising up to the call of producing high quality requirements and turning the tide of ICT projects, this post points out the tricky nature of requirements and mistakes that BAs can avoid when compiling requirements specification documents.

According to the 1986 paper by Parnas & Clements, “A Rational Design Process: How and Why to Fake It”, designing software in a rational, error-free way from a “complete” requirements specification document is like searching for the philosopher’s stone. I once wrote an article: Agile Software Development Methodology: Remedy For the Incomplete Requirements Specification Document, based on my experience, on how difficult or should I say impossible, it is to write a complete requirements document.

So, what exactly makes writing requirements so tricky? Here are 6 factors to consider:

Stakeholders do not always know what they want and when they do, they’re unable to tell us everything they know. This can happen where a stakeholder assumes that the analyst already has information they don’t have, where the stakeholder hoards information, where the stakeholder is just unable to put into words exactly what they want due to communication gaps or where the stakeholder is unable to anticipate everything he needs due to the simple fact that he is human.
Even if we knew all the requirements to get started, additional but useful facts only become obvious after we have started the design work and in some cases, when the system is being tested. As we encounter new information or product defects, analysts often need to go back and refine the requirements while minimizing lost work.
There are too many details surrounding the development of a system that humans are unable to comprehend. This is where bounded rationality comes in. Human beings, no matter how intelligent they are, are faced with 3 main constraints: 1) Only limited and often unreliable information are available to develop requirements 2) the human mind is limited in its capacity to process the available information 3) Most projects are time-bound, thereby shortening the time it takes to fine-tune requirements
External factors, over which we have no control, can cause requirements to change
Even where concerns are separated, errors in stating or representing requirements can still be made since it is handled by humans
We are often influenced by pre-conceived ideas and notions (from lessons we’ve learnt, cases studies or from formal institutions), which may cause us to misrepresent requirements along the line.

Bearing all these in mind, all we can do is try. Parnas & Clements suggest that we should still create requirements specifications documents as if we had followed a rational process

So, what exactly are requirements specification documents?

In clear and simple terms, a requirements specification document outlines what the software is expected to do. Between the users and the analyst, an agreement must be reached on what actions users can perform and what responses they can expect to receive from the system. This is only logical. It serves as a contract between the analysts and the customers.

Why would you need one?

Requirements documents play a significant role in the design process and are used as a reference point for system design throughout the software development lifecycle. How would developers know what to develop without one?
It’s a document where requirements are recorded and reviewed for approval – the scope of the project is explicitly contained in the Requirements Specification Document.
It prevents making spontaneous decisions about requirements as the project evolves. Programmers should not be the ones deciding what is best for users
To avoid duplication and inconsistency. Programmers or stakeholders may ask the same questions repeatedly and receive inconsistent answers each time. Having a central point of reference will help to clarify grey areas throughout the duration of the project
A software requirements document aids accurate estimation of the amount of time and resources needed to conclude the project
It provides insurance against personnel turnover. Requirements will not exist in one person’s head and knowledge of user requirements can easily be transferred to other projects even when analysts or developers leave the team
Provides a basis for writing and developing test cases

On writing better requirements specification documents, what is the way forward?

While there are no excellent ways of writing the requirements specification document, there are some mistakes we can consciously avoid.

Poor Organization
Avoid poor organization by defining the structure of the requirements specification document before you start writing. Each requirement should be defined in one section and one section only.
Confusing/Inconsistent Terminology
Use a glossary containing the definition of all the terms used in the requirements specification document; this will ensure that all the members of the team understand what the document is about.
Boring Prose
Don’t use plenty of words where you can use a picture or a formula. Also, repeating facts in different sections of the documentation increases the burden on the reader and causes inattentive reading which in turn may lead to undiscovered errors. Repetition of requirements in various places on the document would also require maintaining different sections of the document when changes need to be made. The resulting read should be detailed and precise but not boring.
Myopia
Requirement Specification Documents should be written clearly without assuming that readers have a prior understanding of the requirements. This would prevent misunderstanding further down the line. All assumptions should also be clearly stated. Areas where information is not known or is likely to change should also be highlighted.
Solution-Bias
Requirement Specification Documents should not describe solution ideas or contain any implementation details. It should describe only “what” the business needs and not “how”.
Requirements Verification
Requirements should be verified with users again and again. Since requirements cannot be gathered all at once, they need to be evolved. The document should be continually reviewed whenever changes are made and updated whenever requirements are discovered.
Presentation
Presentation does matter.

Use descriptive titles
Use bullet points and short sentences to assist readers in staying focused.
Use the active voice in writing requirements
Use a table of contents so that readers can navigate the document easily
Avoid the russian nested doll effect – Requirements within requirements. Always break down parent requirements and never use “and/or” in your requirements documents – this would mean that several requirements have been nested together in one and can easily lead to confusion.

8. Remember the acronym FUC4TM
Requirements should be

Feasible
Unambiguous
Complete
Cohesive
Consistent
Correct
Testable and
Modifiable.

How else can Requirements Specifications Documents be improved?

Join the call and share your thoughts.

Stephanie Famuyide is a business analyst blogger that blogs about all things business analysis. Visit http://businessanalystlearnings.com where I provide practical tips you can apply on the job.

What Every Business Analyst Can Learn From Journalism: The Art of Intelligent Questioning

Stephanie Famuyide — Sat, 02 Mar 2013 15:44:00 GMT

"Garbage in, Garbage Out" - To elicit accurate requirements, the business analyst must learn to ask the “right” questions “the right way”. The manner in which questions are delivered and the composition of these questions have a direct impact on the usefulness of the responses we receive.

If your questions are properly and thoughtfully framed, not only will you get the appropriate response, your stakeholders will also go away with a feeling that you indeed understand and empathize with them. They should come out of an interview session feeling “understood” not “interrogated”.

According to Donald Rumsfeld’s infamous (but accurate) quote in 2002 regarding the Iraq war:

“There are known knowns - things we know that we know.

There are known unknowns – things we know that we do not know

And there are also unknown unknowns – the things we don’t know we don’t know.”

The known knowns and known unknowns are easier to manage – by asking confirmatory questions to test the accuracy of existing knowledge and asking direct questions to elicit information on grey areas. How then should Business Analysts handle what they don’t know they don’t know? The answer is pretty straightforward:

By opting for open-ended questions.

Open-ended questions are more appropriate where you have limited knowledge on stakeholder issues or expectations. Questions that start with the 5 Ws and H: who, why, what, where, when and how tend to elicit more thoughtful and insightful responses when compared with those that start with: Would, Should, is, are, do you think, and the like.

For example, instead of asking: Do you open physical files for the different documents you receive? It’s better to ask: "How do you manage the documents you receive?"

Using the 5Ws and H also implies that you want to know what your stakeholders' opinions are and you're not just looking for an opportunity to state your own opinions through a leading question.

From Verbal to Visual: Reviving the Lost Art of Prototyping

Stephanie Famuyide — Sat, 16 Feb 2013 09:49:00 GMT

“Something is happening. We are becoming a visually mediated society. For many, understanding of the world is being accomplished, not through words, but by reading images –

Paul Martin Lester, “Syntactic Theory of Visual Communication

Research has shown that communication with a visual dimension is more effective than communication without. Herome Bruner of New York University revealed that people remember only 10% of what they listen to, only 20% of words they read and about 80% of what they see and put into practice.

Though visual communication is deemed more powerful than verbal communication, a combination of the two, carefully and intelligently blended can be extremely powerful.

Look around you. Visual communication is everywhere - from presentations at work to directions on the street. Today’s generation now lean towards a different mode of learning; there's a pervasive preference for videos, pictures, flashcards and presentations. Communication is now achieved visually more than ever.

Beyond the ability to deliver compelling presentations, the perfected art of visual communication can be extremely useful when dealing with stakeholders. Understanding a 10-page business requirements document can be made easier if the business analyst employs the use of mock-ups/prototypes and process diagrams.

Edward R. Tufte has emphasized that “To envision information—and what bright and splendid visions can result—is to work at the intersection of image, word, number, art.”

Employ the use of charts, diagrams, tables and colours wherever you can to deliver a powerful combination of the visual and the verbal.

Next time you're churning out that business requirements document, consider using pictures instead of a thousand words....

Stephanie Famuyide (Stephanie@businessanalystlearnings.com)

http://businessanalystlearnings.com